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m<?SmCMi^ FXBL0 

The presented invention i« concerned with 
teiecb#ounicati^^ teelmology, tl» invention espe- 
S cially targete on > method for the forming of e termi- 
nal independent interface for security fiuictlonsi be- 
tween a service and its recipient while using etan* 
dardlzed page description language* 

10 wktmstoom oT vm xmivbsttxcn 

The use of the wireleee application protocol 
(HAP, Wireless Application Protocol) is becoming more 
comraon in solutions, where a connection between tnobile 
terminals/ as a mobile phone, and internet applied'- 

15: tiohsi for instance e-raail, the WWW (World Wide Web) 
and newsgroups, is needed. The wireless application 
protocol offers an architecture which fits mobile 
phones, the browser programs of mobile phones and the 
WWW into a working wholeness. The HTMl*- language CRyper 

20 Text Markup Lar^ruage) used in the WWW can, when neces- 
sary^ be transformed into WML {Wireless »terkup Lan- 
guage) which has been developed for the wireless envi- 
ronment, when data is transferred to mobile stations. 
At present the description language of the WAP« 

25 standard is the WKL*^ language, but also any other de*- 
scription language in accordance with the coming WAP- 
standard can be comprised as the language • 

The wireless application protocol coi^prises 
five layers: the wireless applicaticm environment 

30 (WAS, Wireless Application Environment), the wireless 
session layer (WSL, Wireless Session Layer), the wire- 
less transaction layer (WTl,, Wireless Transaction 
Layer), the wireless transport layer security layer 
(WTLS, Wireless Transport Layer Security) and the 

35 wireless transfer layer (WDP; Wireless Datagram 
Lay<sr) • With wireless application environment it is 
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Thaant for iiietanee WPA {WTA, Wiroleae Telephone Appli- 
patloxi) or any oth€ir suitable environment* th^re is 
furthermore a sYStem dependant layer as the lowest 
layers , which defines the way in which the informa- 
5 tion is transported inside the system in question. At 
present - the last accepted. WAP-*specification version 
nuiober is 1»3/ 

The especial purpose of the WAP -architecture 
is to make it possible to use, among other0> services 

10 in the internet on the mobile terminals, the data han- 
dling abilityi screen size or memo^ capacity of which 
is small or limited. Terminals like the ones described 
are for instance mobile stations and PDAs {PDA, Per- 
sonal Digital Assistant) . The WAP- specification does 

IB not take a stand on how the air interface is realized. 
This makes it possible for several different opera- 
tors, terminal' manufacturers and program manufacturers 
to benefit from the possibilities theit the standard 
brings with it. 

20 At present the problem is how to use the 

'Standardised page description language, for instance 
imu, for the -making of an encryption and a digital 
signature without restricting to \a certain encaryptlon 
or signature method or terminal. Furthermore, a prob- 

25 lam is that for instance the WTLS- encrypt ion handling 
the encryption of data in the WApx-protocol is not a 
pure end-to*end encryption? the encryption can be de- 
crypted in between. The contents can be accessed and 
thus the risk is that it can be altered. Thus, the 

30 confidence, in the data contents and its integrity is 
lost» 

A certain solution is to use ' manufacturer 
specific page description languages, for example . a 
manufacturer specific WML-language, which still is not 
35 in accordance with a standard. This leads to that all 
the cpmponents in the network and the terminal at the 



■.3 

of the c|tiukln do not uxadarstand^ the manufactiurer 
- specific page description language/ 

Another solution is to use script language, 
for example WMtjScript, but the prc^lem with this al- 
5 ti^riie is the lack of functionis! neoeaeazy for en- 
cryption and signature. Purthenaorei the inconvfluciience 
with using the script - language is that the terminals 
browser program does not necessarily support the use 
of the script language. 
1(K In additicm^ a situation where new, functicms 

are wanted to be added to the service becomes, trouble/** 
some. The producer of the service has to translate the 
program after each change^ The changes made are often 
dependent on the terminal, so different changes have 
15 to be made on different programs. 

wSUISCX vllr XIUS - JUNVtSfffXxwfil 

The purpose of the invention is to remove or 
at least significantly alleviate the disadvantages 
20 mentioned above . Especially, the invention is con^^ 
ocunoed with a n^w kind of method, with which « termi- 
nal-'independent interface can be offered to the serv- 
ice provider, through which interface, fimctions con- 
cerned with the security measures can be called » 

25; 

SraBipytY OF SHK XNVEOTXOSI 

llie present . invention is concerned with a 
method for the fonning of a terminal*- independent in- 
terfmoe for security f uanations between the service and 

30 the recipient while using a standardised page descrip* 
tion language « With standardized page description lan- 
guage it is referred to for example the WMXi« language. 

In the method in accordance with the Inven*- 
tion the fxmction call requests concerned with the se*- 

35 curlty measures are encapsulated in the service into a 
document in accordance with the standardized page de- 



aqiriptlon language * X£ the page da^criptlon language 
is WML, the do-element with a ty^>e-attribute is ueed^ 
with which do-type the security meaeures to be per- 
f c^rmad to the proxy- seryer are defined • 
S With service it is referred to a eervice of- 

fet^ed by a sisxvlce provider^ where eecurlty measurea 
are needed* Security meaaures are for inetence a digi- 
tal signature, the verification of * a digital signa- 
ture, the encryption of data, the decryption of data 

10 and ao forth • A service provider is for instance a^ 
bank, a credit card company, an Internet shop etc. A 
service is therefore for instance a bank service that 
demands security measures* The service adds the iden- 
tity data referring to the final recipient of the 

15 document, into the document fortned by the service » The 
service transmits the document to the proxy*- server. 
Said functions axe called with the proxy- server for 
the realisation of said security measurea. The func- 
tion calls can be realized on the proxy-server itself 

20 or they can be transmitted to a separate PKI-sexver/ 
\d&ich takes care of the security measures 1 In said, ae-^ , 
curity measurea a symmetric or an asymmetric method is 
used for the signature and/or encryption. Methods like 
these are for instance 2DEB {3DBS, Triple Data Bncryp-' 

25 tion Standard) and RSA (RSA, Rivest Shamir Adleman} . 

The protocol uaed by the recipient is checked 
with the proxy-server. The document in accordance with 
the standardissed page description language handled 
with the security measures received from the service 

30 ia transmitted with the proacy-server to the recipient 
with the transmission protocol understood by the re- 
cipient* If the page description language is mh, the 
document in accordance with the standardized WML- 
language is, if necessary, changed to a manufacturer 

35 ' specific WML- language, XML- language (XML, extended 
Markup Iiangtiage) or to another form understood by the 
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recipient. If the recipie^^t " oaimot interpr^^ the re- 
ceived document, it can be ignored* 

The sending of information between thi^ eery- 
ice and the recipient can be activated in different 
5 ways* In a certain case, the recipient first sends a 
request, to which the aiervice responds. In - another 
case the service sends information to the reoipiwt 
with a push-method withc«ut a request frow the recipi- 
ent. In the before mentioned case the proxy- server 

10 checks the protocol used by the recipient in the re- 
quest and transmits the document, received from the 
service as a response to the request, in accordance 
with the standardised page description language which 
has been handled with security measures to the recipi-* 

15 ent in accordance with the protocol used by the re- 
cipient. 

In the latter case the recipient does not 
firist transmit a service request to the service, but 
the service uses the push- function. In this case the 

20 service sends the doctunent to be sent to the recipient . 
to the proxy-^server aind at the same time identifies 
the recipient, to which the proxy* server later, trans- 
mits the document handled with the security- measxn:€Ss« 
The identification data is for instance a network 

25 identity or an MSlSJDW-number (MSISDN, Mobile Sub- 
scriber ISDN) . A network identity is an unambiguous 
user specific identifier, to which signature and en- 
cryption keys have been attached during the creation 
of it. Corresponding data pairs are maintained on the 

30; proxy-server, witb which the recipient's identifica- 
tion data and transmission protocol are tied together« 
The proxy- server can choose the right transmission 
protocol on the basis of the identification data con- 
nected with the recipient received from the service. 

3S Becaxise of the present invention the faction 

offering services to a fixed line or wireless terminal 
which demand security measures does not need to care 
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eJpput the recipient's terminal or its attributes. An 
iiiterfAee is offered to the faction offering a serv- 
ioey thrpugit which it calls the necessary security 
licensures in a terminal independent way. The security 
5 ftonction requests are always sent from the service in 
accordanoe with the standardized page description lan- 
guage » Because of the interface the faction offering 
se3nrlceB does riot need to update its software with 
terminal specific changes, 
io Because of the invention the functions con- 

cerned with the digital signature and encryption can 
be' taken intp widespread use regardless of* peg«t ^e-* 
scripticxi language. 

15 BRXSV nHSCHIPTXON OF THK DRAWINOS 

The accompanying drawings, which are included 
to provide a further understanding of the invention 
and constitute a part of this specification; illus«^ 
trate embodiments - of the invention ' and together with 
20 the description help to explain the principles of the 
invent icHi. In the drawings: 

figure 1 presents the ftmctioning of the 
method in accordance with the presented invention, and 

figure 2 presents a certain advantageous sys- 
25 tern, in which the method in accordance with the invckn- 
tion can be realized.. 

dmjaiIjSD dbscriptxon or THS xwrmrio^ 

Figure 1 presents the functionality of the 
30 method in accordanoe with the invention. The method in 
accordance with the invention id concemed with the 
forming of a terminal independent interface for the 
security measures between the service and the recipi- 
ent while using standardized page description Ian- 
35 guage. Security measures are for instance, a digital 
signature, the verification of a signature, the en- 
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cary^ticm of data, the decryption of data etc* With 
flttodardized page de8cri]^ion It ie referred 

to. for instance WML- laiig^ 

in accordance with block 10 the neceaeary 
5 fimoit^n reque?^^ coticerxied with the security measurea 
arei exicapaulated into thi^ dbcta^ in aocoawla«ee with 
the standardissed page deBcriptiow laaguage. The serv- 
ice can send information to the recipient with the 
push»method without asi actual dervic© requeat* In the 
10 second alternative the recipient haa, before block 10, 
Bisnt a aervice request for the receiving of informa- 
tion. In this case the seicvice request made , by the re«* 
cipient containe the identification data of the re- 
cipient, on . the basis of which the service can send 
15 the response to the right recipient. . 

The service attaches the identification data 
of the recipient into the document, block 11. in ac- 
cordance with block 12. the document is transmitted to 
the proxy-- server. With the proxy- server said functions 
20 are called for the realisation of said security meas^ 
ures, block 13. Said functions can be called in the 
proxy- server or in a separate PKZ-seicver (PiCI, Ptflillc 
Key Infrastructure) . A symmetric or an asymmetric 
method is used for the signature and/or encryption ' 
25 concerned with the security measures. 

In accordance with block .14 the protocol used 
by the recipient is checked with the pro?cy- server. The 
proxy-server maintains corresponding data pairs, with 
which the identification data and transmission proto- 
30 col of the recipient are tiod together. With the iden*- 
tification data it is for instance referred to a net- 
work identity or an MSISDN-nuunber . The network iden^ 
tity is an unambiguous user specific identity, to 
which has been attached signature and encryption keys 
35 during its creation. The prcu^'server searches i-denti^ 
ficatlon data of the recipient defined by the service 
and can thereby choose the right transmission proto<^ 
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col, Tha p3fp3cy-»«rv<^r transmits the document, in ac- 
cordance with the page description language, handled 
with the security measures to the recipient using the 
transmission protocol understood by the recipient r 
5 block 15. if the recipient cannot interpret the re- 
ceived <3tocument^ it can be igf^ored. 

Because of ^ the invention the security f unc*- 
tion requests are always sent using the standardized 
page description language. Because of the interface 

10 the faction offering services does not need to update 
its software With terminal specific changes. ' 

The example in adoordanoe with figure 2 con- 
sists of the service BB, the proxy-server 3C, the PKI- 
server PKI and the recipient WIB» With service BE it 

15 is referred to for instance a bank's, a credit ins ti 
tut ion* 8 or an bxiline trader's service in which secu* 
rity measures are taken advantage of,. Security meas- 
ures are for instance a digital signature , the verifi-^ 
cation of a signature, the encryption of data, the de-> 

20 cryption of ^ata, etc. The proxy r server can execute the. 
demanded security functions itself or send the funo-^ 
tion requests concerned with the security measures to 
the PKI -server PKI. 

In the example in accordance with figure* 2 

25 information between the service BE and the proxy 
server 8Q is transmitted in accordarice with the stm- 
dardisBed W^al*description language. The information be- 
tween the proxy- server 8C and the recipient • WIB is 
transmitted in accordance with WML-language, manufac- 

30 turer specific WML-language, XMli-language or in accor- 
dance with another form of data transfer suited to the 
purpose. With recipient the WIB it is advantageously 
.referred to a terminal, a browser program of a termi- 
nal, software of a teiiuinal or other, with which the 

35 information sent from the prosQ^-server BC can be han-* 
dled^ 
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In the following the functioning of the exam- 
ple in accordance with figure 2 is explained more spe- 
cifically. Even though it is presented in the follow- 
ing that the page description language between the 
5 service and the proxy-server is WML / it can be any 
other, language suited for .thi purpose ^ for example 
XNL« HTMZi (Hypelr Text Markup Language), WMS^ {HX^, 
Haxidheld. device Marjcup Language) etc. The- starting 
point of the invention is to function in such a way 
ID that the data traffic between the service BE and the 
proxy 1- server SC is in accordance with standardised 
page description language. 

In this exataple the do-element is uied with 
the type-^attrlbute. The type-attribute gives the re-' 

19 ceiving party a reference on how the user of the do* 
element wants it to be' used^ Most of the typa^.. 
attributeis are reserved, but es^perixEiental and manufac-- 
turer specific ones have been defined into the Ian-* 
guage. These attributes can be used to broaden the 

20 WML-language, but still simultaneously preserve the . 
definitions of the WML-speclf ications. When manufao-* 
turer specific type-^att'ributes are used, the proxy^ 
server. 30 can interpret the requests concerned with 
the security measures from a standard according WML- , 

25 document, whereas standardlaed WAP-clients ignore this 
inf oxrm^tlon • 

The Interface and the way in which the serv- 
ice BE sends security f junction requests to the proxy- 
server is described in the following. A signature re- 
ad quest has been presented in the following.. 

<do type«»''vnd»smarttrust.sign'' label«^SIGir optional- 
''true"> . , ... 

'<refresh> 

35 <setvar naiiie«-^signParam*' vaiue**^ f oo" /> 

<setvaamaiiiee^transID*value«^TI«lNSACTION_II^^ . 
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<5etvar name*" options" value««^'bPTIONS'V> 
<i8etvar name-<' k#yldType'' value«^X2345'f /> 
<setvar name««^' keyld'' value»^'KEy_ID*/> 
<setvar name«''userIDTyp©'' value="12345"/> 
5 <aetvar nam^»-"u8erID" value-'' USBRID"/> ^ 

<setvar names*" irtodif labia" value*" true | false" /> 
</re£resh> 
</do> 

iO The label-attribute in the do-elemant has at 

tnoat a length of six aharacters and it only servea a 
purpose as a giver of information. The . optional - 
attribute in the do-element makes it possible for the 
redipient WIB to ignore the used do-element. 

Of the columns appearing in the table WIG rer 
f ers to the realisation way of the invention and WAP 
, to thc» realisation* way of the nearest technical stan- 
dard. In the columns »WM"" means mandatory and "0» op- 
tional. 



Attributa 




Bacplanation 




K2U? 


UserlD- . 
Type 


String 
(Inte- 
ger 
Value) 


Defines the user iden- 
tification type which 
the seryice fiB usea^ 
with which it is placed 
abreast with the 
NID/MSISDN used by the 
proxy-server SC. 
NID - 1 
MSISDti » 2 
BBSPECIFIC » 3 




M 


UserXD 


String 


Identifies the user: 


M 


H 


Sign 
Param 


String 


The name of the URL*- 
parameter which is re- 
turned in the HTTP GST- 




M 



11 







request, si^ecl by the 
recipient WIB, 






TransID 


Strlrig 


An urtajnbiguous transac- 
^ion marx. 


M 


M . 


Options 




In use only in WAP- 
client programs. 


0 


M 


KeylD 
Type 


String 
(Inte- 
ger 

Value) 


In use only in WAP- 
client programs 


0 


M 


KeylD 


Stifing 


In. use only in WAP- 
client programs. 


0 


M 


Modifi- 
able 


String 


Defines if the signed 
parameter is static 
("false") or dynamic 
("true«) . 


0 


0 



The interface and the way in which the serv-- 
ice BB sends security, function requests to the prcocy- 
server is described in the following. Another way to 
5' make a signature request is presented in the follow- 
ing. The MAC (ISO 9707) method is used. On the basis 
of the request the fed iaformatiott is signed with the 
3DES-method (3DBS, Triple Cat a Encryption Standard) in 
an external CBC-mode (CBC, Cell Block Cipher) using 
10 two keys. 

<do typew^vnd/smarttrust.kmac" label«^KMAC* optional- 
''true*'> 

<ref resh> 

15 <setvar name«" signParam" yalue=*'' f oo'' /> 

<setvar name»-''transID^ .value'<' TRANSACTION Xiy'/> 
<setvar name-^userXDType'^ value«^12345''/> 
<setvar name**^ user lir value"-^6sBRID^/> 
<setvar haroe^^i^odifiable* value-*' true I false*' /> 
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</refr€ish> 
</do> 

The Xftbal-attribute in the do-element haa at 
5 most a length of six characters and it only serves a 
purpose as a giver of information. The optional 
attribute in the do-element makes it poaaible £or the 
recipient WXB to ignore the used do-element » 



Attrib- 
ute 


Type 


Explanation 




WAS 


UaerlD-- 
Type 


String 
(Inte- 
ger 
Value) 


Defines the user iden'* 
tif ication type which 
the service BE useS/ 
with which it is placed 
abreast with the 
NID/MSISDN used by the 
proxy-'server SC. 
NID « 1 
MSXSON - 2 . 
BESPECIFIC « 3 


M 


n 


UeerXD 


String 


Identifies the user. 


M 


M . 


Sign 
Param 


String 


The name of the URL- 
parameter which is re- 
turned in the HTTP GET- 
request, signed by the 
recipient WIS. 


M 


M 


TransID 


String 


An unambiguous tr ansae-, 
tion mark. 


H 




Modifi- 
able 


String 


Defines if the signed 
parameter is static 
{"false") or dynamic 
("true") . 


0 


o ■ 
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The intorf^ide ahd the way In which the aexv- 
ice BB sends security ftrnct ion requests to the proxy- 
server is described ; in the followiiig. An encryption 
request is presented in the following, on the basis of 
5 the request the : input information is encrypted using 
the 3DeS"inethod iri an external CBC-niode using two 
keys. 

<do type«^'vnd.siaarttrust •encrypt'" label«^BNCR* op- 
10 tional-^true"> 
<refresh> 

<setvar name*^ encrypt Paranr* value"** foo*/> 
<setvar name»"userIDType'' value*'' 12345'' /> 
<setvar name'-^userljy' value*s^USERIiy'/> 
15 </refresh> 
</do> 

The "X« in the table mearxs that the nearest 
technical standard WAP does not at present support 

20 this fianction. 



Attrib- 
ute 




Sxplmnation 






Encrypt 
Param 


String 


Character line which 
contains the name of 
the variable which the 
recipient WIB encrypts. 


H 


X 


OserlD- 
Type 


String 
(Inte- 
ger 
Value) 


Defines the user iden- 
tification type which, 
the service BE uses, 
with whieh it is placed 
abreast with the 
NID/MSISDN used by the 
proxy-'Server SC, 
NXD « 1 


M 


X 
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MSISDN - 2 
BBSPBCIFIC - 3 






UserlD 


String 


Identifies the user. 


M 


X 



The interface and the way which the servioe 
BB sends security fuaaction requeste. to the proxy- 
server is deacribed iri the following. A decryption re- 
5 quest ie presented in the following. On the has id of 
the requeet the encryption is decrypted with the 3DBS- 
method in an axtemal CBC-tnode using two keys, 

<do type«"vnd.smarttruat. decrypt'' label»«^DECR" op- 
XO tlonal«"true"> 
<refre-sh> 

<aetvar name-'' stringTo Decrypt" value-" plain'' /> 
<setvar naicie-^^decryptedString" value-" foo''y> 
<setvar naiae-"userIDType" value> 12345" /> 
15 <setvar name*-"usernr' value«f'USBaiD" /> 

</refre8h> 
</do> 
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Attribute 


Type 


Expianatipn 


WIQ 


WAP 


StringTo 
-Decrypt 


String 


Information which i» en-- 
crypted using the proxy- 
server end Which the re^ 
cipient WIB decrypts » 


M 


X 


De- 
crypted 
String 


String 


A variable; to where the 
information vrhich has 
been decrypted by the 
recipient WXB to plain 
text is set. 


M 


X 


UaexiD- 
Type 


String 
(Inte- 
ger 
Value) 


Defines the user identi- 
fication type which the » 
service BB uses, .with 
which it is placed 

NID/MSISDN used by the . 
proxy-server SC» 
NID = 1 
MSISDN 2 
BBSPECIFIC - 3 


M 


X 


UserlD 


String 


Identifies the user 


M 


X . 



Furthearraore, the interface between the serv- 
ice BS and the proxy- server SC is described in the 
following; When implementing security measures it is 
H possible to take advantage of the first function 
call's output as the argutnent for the second function 
call. Such a situation can arise in for instance the 
following situations. 

!• The service BS sends information, which is 
la encrypted wing the proxy-server sc and 

which the recipient WIB decrypts. The value 
of the decrypted variable can furthermore 
be for instance shown to the user or be * 
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used as an aargument for an encryption serir* 
ice. 

2, The information is signed before performlang 
the encryption* 
5 In the following it is exemplary presented, 

how the data in the oontract** variable is signed using 
the do-bype and then how the * signed data in the con** 
tract-variable is encrypted using the do-type (oon- 
tract consists of all the variables prefix, amount and 
io suffix) . 

<do type-^vndpsmarttrust .sign" optional*" true''> 
<refresh> 

<8etvar name*-" modifiable" value-'' true" /> 
15 <s«tvar name«"'signeciParam" value=»" contract" /> 

oetvar name«*" uaerlDType" value*" yf/> 
<8etvar name"*"userliy value«"test user"/> 
</refresh> 
</do> 

20 

<do type**" vnd*smarttru8t, encrypt" optional"*" truQ'^'> , 
<r.ef resh> 

<8etvar name*" encrypt Par am" value««" contract" /> 
<setvar name"-"u8erIDTypo" value-" 3" /> 
25 <setvar name*" user ID" value"«"test user"/> 

</refre8h> 
</do> 

<o> 

30 <anchor> 
<go 

href"*" http : //www . backend » com/f ile7contract*$ <pref ix) $ ( 
amount) $(suffix)"/> 
'< /anchor > 
35 </p> 
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In the following it is exei^plary presentsd^ 
how the proxy-server SC can alter the presentation 
form- of the generic do -type in order to correspond to 
the receiving terminal while using security functional 
$ The recipient KIB requests sensitive informa- 

tion from the searvice B&. The service BB transmits the 
following nMli-card as a response to the request to the 
proxy- server SC. , 

10 <wml> 

<card> 

•<do type-^vnd. smart trust ^decrypt'' optional-" true" > 

<refresh> 

Oetvar name-^ stringToDecrypt" value>«^ account 

15 balance : -100 FHr/> 

<setver name-^decryptedString* value-" output''/> 
<setvar name«^userIDType" value«i^'3"/> 
<setvar name-^uaerliy value*-" test usea:"/> 
</refrash> 

20 </do> 

<p> 

$ (output) <! — displays the data without padding 
bytes — > 

</p> 
25 </card> 
</wiia> 

The projcy-searvor SC encrypts the character 
line ''aooount balance; -lOOFlM* and transmits the in- 

30 formation to the recipient WIB. The recipient WIB da- 
crypts the encryption and stores the data into .the 
output Wariable, vAlch value can be for instance shown 
to the user. 

It is described as an example in the follow- 

35 ing, how the recipient WIB sends confidential informa- 
tion to the service BS. The data to be >sent is for in- 
stance a. password. The user enters the password to a 
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given input field. The recipient WIB encrypte the 
value of the pwd-variable (password) and sends it to 
the proxy- server SC. 

5 <wml> 

<card> 

<P> • , 

* <lnput title-" enter password'' t^fl'^text'' 

name«»" password^ /> 

io </p> 

<dp. type-" vnd * amarttrust . encrypt" optional*^ true''' > 
<refre3h> 

<aetvaaC naiae«" encrypt Pa ratrf* .value-^pwd'V> 
<setvar name«^userlDType" value«"3"/> 
is <setvar name-*' userlD" value-'' test user"/> 

</re£r©3h> 
</do> 
<p> 

■ <anohor> 

20 <go href«"http: //www, back-end • com/f il©'?pwd-$ (pas 

aword)^/> 

</anchor> 
</p> 
</card> 
25 </wml> 

The proxy-server SC decrypts the ejaoryption 
of the pwd* variable and sends an HTTP GET- request .to 
the service, which consists of the stored, plain text 
30 of* the pwd- variable . . 

OBT /£ile?pwd»« "password entered" HTTP /l,l 

It is described as an exanqple in the follov- 
35 ing, how the recipient WIB signs- and encrypts the re«- 
oeived payment request or contract received Crota the 
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Sdxvioa BE. The recipient HIB uses the MAC-method for 
the signature. The exaTqple consieta of three phaaea: 

, 1 • Encrypted data is sent to the recipient 
WIB, that ccmaiatB of a frame agraenentt 
S «pref Ix" and «auf f Ix" , Theae can be any 

atatic data, for instance ^refilled fields « 
2* The contract" -variable consists of the 
following data* "prefix" + the input of the 
user ^ "suffix". The data said abcsve is 
10 signed after the PIM- inquiry confirmation 

(PIN, Personal Identification Nunft>er) * 
3* The data in the "ocmtraot* -variable said 
above is encrypted, 

15 <wml> 

<card> 

<do type«*^ vnd • smarttrus t . decrypt optional-^ true*' > ' 

<refresh> 

<setvar naine««^'stringToDecrypt'' value«*I wish to 

20 buy"/> 

<setvar name-^decryptedString^ value*-* prefix* /> 
<8etvar namei^'userlDType^ value*^3*'/> 
<setvar namev^^'userlD^ value«<^test user*^/> 

</refresh> 
25 </dQ> 

<do t ype:^' vnd. smarttrust. decrypt'' optional*-* true* > 
<refresh> 

<s€tvar name-^stringToPecrypt" value-* PoJceroon 

30 Figures* /> 

<8etvar name^'decryptedstring* value-^ suffix* /> 
<setvar name^^'userlDType* value-* 3" /> 
<setvar name-*u5erlD" value-* test user^/> 
</refresh> 

3i5^ </do> 

. ■ <p> ' 
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<input type-^'text" name*^ amount^ />• 
</p> 

<do type-'' vnd.smartt rust ♦kmac" optionaWtrue;^> 
5 <xafreah> 

<setvar name*" modifiable" value«"true*'/> 
<setvar name**" algnedParazn'' . value-^ contract*' /> 
<aetvar .narae^^ueerlDType" value«-''3''/> 
<s0tvar name"*'' user icy' value-" taat u3er'''/> 
10 . </re£resh> 

</do> 

<do type-'' vnd^smarttrust. encrypt'' optional-^' true'' > 
<refresh>. 

15 <8etvar name-" encryptParam" valuer" contract" /> 

. ■ <eetvar name-"userlDType'' value-" 3" /> 

<0etvar name"*"userliy valueVtest u8er''/> . 
</refre8h> . 
</do> 

20 . • 

<P> 

<anchor> 

<go href-"http t //www. back-end,, com/f lle?contractT$ ( 
pref ix) $ (amount) $ (auf fix)" /> 
25 </ahchor> 
</p> 
</card> 
</wml> 

30 The proxy- server SC decrypts the encryption 

and verifies the . aignature. Thereafter the .proxy- 
server sends an HTTP GBT^ request to the service BE. 

GST /file7contract«'^ I wish to buy X ^okemon fig- 
35 uras"&KMAC_FIEIiDS-"contract" HTTP /l,i 
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The request furthermore consiats of the 
KMAC^FlBLDS-parameter, which indicatea the verified 
parameters. 

It is described aa an example in the f ollow- 
5 liiQt bow the recipient WlB eigxuai and encrypta the pay^ 
ment. recjueat or contract, received from the aervlce 
BB. In this example the recipient WIB tiaea an RSA*^ 
aignature. The example conaista of three phaaeat 

1. Encrypted data ia eent to the recipient 
WIB, that consiata of a frame agreement! 
"prefix" and "auffiac", These can be any 
etatic data, for instance prefilled fields.* 

2. *he "contracts-variable . conaleta of the 
following data: "prefix" +• the input of the 

.^5 user + . "suffix" • The data said above is 

signed after" the PIN- inquiry confirmation 
(PIN, Personal Identification Number) . 

3. The data in the "contract" -variable aaid 
above ia encrypted. 

20 

<wml> 
<card> 

<do type-" vnd. smart trust, decrypt" optional-^ true" > 
<refresh> 

2S <setvar name«^ stringToOecrypt* value-^I wish 

to buy-'A 

<setvax nainex^ decrypt edstring^ value-^ prefix* /> 
<8etvaf name***userlDType* value«^3r/> 
<setvar name«^userlir value-'' test user'V> 
30 K/refresh^ 
</do> 

<do type'-^'vnd.Qiuarttrust. decrypt" optional-^' true" > 
<refresh> 

3i5 ' <setvar narae«"" stringToDecrypt" value-^ Pokemon 

figures" /> 

<setvar names*" decfyptedString" value"-* suffix" /> 
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<8etvar name-'' user IDType'^ value-'' 3" /> 
Oetvar namd««*^userliy vaiu€*^test .us«r*'/> 
</refresh> 
</do> 

; 5 

<P> 

<input type'^'text" name*^ amount" 
</p> 

10 «Jo type*" vnd.sraarttrust. sign" optional*" true* > . 

<r6£reah> . 

. <setvar nama-" modifiable" value«"trua*'/> 
<8atvar name*'' signedParant" value**" contract* /> 
<9otvar name*" user IDType" value«»" 3" /> - 
is <8etvar name*" user ID" value«"test usex"/> 

</re£re3h> 
</db> 

<do .type*" vnd*ainarttrust. encrypt" optional*" true" > 
20 <refresh> 

Oetvar name-^ encrypt ParajiT value*^ contract" /> 
<setvar n^e-^userlDType*' value*f3"/> 
<setvar name-^userlD" vaiue*"test use;:"/> 
</refresh> 
25 • </do> 

; ' <P> ' ■ 
<anchor> 

<go href«^http: //www*baclc-end*coin/file?contraot*$. 
30 (prefix) $ (amount)? {suffix)" /> 
</anchor> 
</p> 
</carcl> 
</wiia> 

36 
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. The proxy- server SC decrypts the eneryptioa 
and verifies the signature* Thereafter the proxy- 
server sends an HTTP OBT- request to the service BB. 

5 GET /file?contract«»" I wish to buy X PoJcemon fig- 
urea "&XlR_FlEliDS»" cent ra^ct* HTTP /i.i ' 

The request furthermore consists * of the 
19R_FIELDS •-parameter, which indicates the verified pa^ 
10 rametera. 

In a certain application in accordance with 
figure 2 the <do type> -structxxre is no.t trainsmitted 
as such to the xeolpient* The <do type> -structure can 
be replaced with a manufacturer specific ^QMLScript 
15 plugin function call. The function call referring to 
the signature is for instance of the form 
http I //manufacturer, com (sig, x) . If the reoipi*^ 
ent's tezminal is a computer the signature invitation 
in accordance with the <do type> •-structure is changed 
20 for instance into the XML- signature request from. 

Because of the invention the functions con- 
cerned with the digital signature and encryption can 
be .taken into widespread use regardless of page de^ 
Bcription language used. With the present invcuition a 
25 service calls the necessary security me^astires in a 
terminal independent way through an interface offered 
to the service. The service does not need to care 
about the type of the terminal of the recipient. 

The invention is not limited to solely con- 
30 cem the application examples presented above i other 
variations are possible while staying within, the in-' 
ventive idea defined by the claims » 
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CLAIMS 

1* A method for tjie £ormlzig of a tttrminftl in- 
dependent Interface for security fimctlona between a 
eervlce and a receiver using standardized page de** 
5 ecrlption language, 

characteriaeedin that the method 
oomparisee the following steps s . . 

a) encapsulating in the service the necessary 

* ' function call requests concerned vith the security 
10 measures into a document in accordance with the stan- " 
dardised page description language; 

b) including the identification data of the re- 
- cipient into the document; 

c) transmitting the document to the proxy-server; * 
15 d> calling said functions with the .proxy-server ■ 

for the .realisation of said security measures; and 

e) checking the protocol used by the recipient 
with the projcy- server; ' • . . 

f ) transmitting the document in accordance with 
20 the standardised page description language Kamdled 

with the security measures, received from the service, 
with the proxy-server to the recipient using a trans-, 
mission protocol understood by the recipient. 

2. Tlie method according to claim 1, c h a r a 
25 c t e r i z e d in that 

g) the received document: is left unnoticed if the 
recipient cannot interpret the document* 

3. the method according to claim 1, c h a r a 
c t e r i s 6 d in that if the page description la|i- 

30 guage is WML, then in step a) t 

using a do- element with a manufacturer specific 
type -attribute, with which the do-type defines bhe se- 
curity measures to be performed on the proxy-server, 

4. The method according to cleiim 1, c h a r a 
3S c t e r i z e d in that if the page description' lan- 
guage is WML^ then in connection with step f ) s 
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changixig ' the dotniment in accordance with the stan* 
dardi«ed WKL^ language to a manufacturer epeclflq HMZi**' 
language, XMi,- language or to sbme other form under- 
stood by the recipient • 
5 5. The method according to cXaim 1, c h a r a 

c t e r .i z e d in that in the signature and/or en^ 
oryption, in eaid security raeaeures, a symmetric or an 
asymmetric method i& used, 

6. The method according to claim X, c h a r a 
10 oterizedin that in step d) : 

calling said functions with the proxy- server from 
the PRX-sesrver for the realisation of said security 
measures, 

7. The method according to claim 1, c *h a r a 
15 c t e r i z e d in that before step a) : 

sending a service request from the recipient to 
the servi.ce. 

8. The method according to claim 7, c h a r a 
Gterizedin that the service req[uest comprises 

20 the identification data of the sender of the service 
request. 

9* The method according to claim 1« c h a r a 
cberizedin that corresponding data pairs are 
upheld on the proxy- server, with which the recipient's 
25 identification data and transmission protocol are tied 
together. 

10. The method according to claim 1 or S, c 
haracterize.din that the recipient's iden^ 
tificatlon data is a network identity, 
30 11* The method according to claim 1 or 9, o 

h a r a c t e r 1 z e d in that the recipient's iden* 
tificatlon data is an MSISt^-nurober. 

12/ The method according to claim 1 or 9^ c 
h a r a c t er i 2 e d in that in connection with step 
3S d)f 
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cheoklng} the trangmieoicm protocol used by the re- 
cipient with the psroxy- server on the basis of the re« 
cipient's identification data. 
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the necessaiy function calls concerned with tiie 
security measures are enc^seled into the docu- 
ment in accordance with standiaidized page desc- 
riotion lahiniaee 

• • -I ., 



the identification data of the recipient is included 
into the document 
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-^1 the document is mediated to the proxy-server 

I ~ — 
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said functions are called iwitih fte proxy-server 
&r the realization of said seinmty measures 
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the protocol used by the recipient is checked 
with the proxy-serva: ■ 



] 
] 



the document handled with the security measures 
\^ ^ is mediated to tiie recipient with a ma^mission 
protocol understood by the recipient 

T 
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